home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-03-06 | 1.5 KB | 37 lines | [TEXT/GEOL] |
- Item 8834373 6-June-88 10:52
-
- From: ROSENSTEIN1 Rosenstein, Larry
-
- To: D1157 All Star Computer, Dev, L Goldman
-
- cc: MACAPP$ MacApp Interest List
-
- Sub: re NewPaletteWindow Bug
-
- I think you are right on both accounts.
-
- Only the topLeft of r is significant because the main frame will be resized to
- the correct size TWindow.Resize is called. But you are right in that some
- debugging utilities check for invalid rectangles such as this.
-
- The second bug is really a bug; it should be subtracting topLeft from wSize.
- As you say, topLeft is always (0,0), so thePort is not damaged and the window
- is resized properly.
-
- I still think it is safer not to assume that the portRect.topLeft is (0,0)
- since the call to the Window Manager is not being made in NewPaletteWindow. It
- is conceivable (although unlikely) that someone would make a change to
- NewTWindow that would change the topLeft. I hesitate to make code that depends
- on assumptions about how other procedure work (such as this).
-
- One way to do this, however, would be to assume that the portRect.topLeft was
- (0,0) and do a check when debugging code was turned on to make sure this was
- true. If it wasn't true, call ProgramBreak to alert the programmer and offset
- the portRect so it was true. That way if someone changes NewTWindow to violate
- the assumption it will be noticed. (This kind of technique is used throughout
- MacApp and is a good example of 'defensive programming'.)
-
- Larry Rosenstein.
-
-
-